Hope it's okay to ignore clippy::type_complexity in all the new places it's popped up.

CI fails with

error: implementation of `std::ops::FnOnce` is not general enough
   --> crates/matrix-sdk-appservice/src/webserver/warp.rs:102:14
    |
102 |             .and_then(handlers::transaction)
    |              ^^^^^^^^ implementation of `std::ops::FnOnce` is not general enough
    |
    = note: closure with signature `fn(&'0 std::boxed::Box<ruma::UserId>) -> &ruma::UserId` must implement `std::ops::FnOnce<(&std::boxed::Box<ruma::UserId>,)>`, for any lifetime `'0`...
    = note: ...but it actually implements `std::ops::FnOnce<(&std::boxed::Box<ruma::UserId>,)>`

which makes absolutely no sense because handlers::transaction is neither a closure nor does it have a UserId parameter.

I have stared at the file and looked at all the (explicit) usage of UserId in matrix-sdk-appservice but am still dumbfounded.

Hope it's okay to ignore clippy::type_complexity in all the new places it's popped up.

Related to that, what's the reason for removing DeviceIdBox? Wouldn't having such type aliases alleviate the need for the type complexity ignores?

Well, I imagine lots of use cases will actually be better off using Arc and three type aliases (Box, Rc, Arc) per identifier type might be a bit much. Also nobody really cared about them when I asked in one of the Matrix rooms a few months back.

Well, I imagine lots of use cases will actually be better off using Arc and three type aliases (Box, Rc, Arc) per identifier type might be a bit much. Also nobody really cared about them when I asked in one of the Matrix rooms a few months back.

Alright, I guess we'll leave it as is.

Not sure what the warp issue is about, doesn't seem to make much sense to me either. Perhaps @johannescpk might help out?

This has nothing to do with warp, commenting out parts of receive_sync_response in the base client fixes it. I'm currently narrowing it down. I suspect an issue with auto traits.

I fixed it. My async_auto_traits crate helped narrow it down a little bit, though actually adding those attributes to the codebase such that they can stay in seems very hard since it also resulted in different errors that I didn't fully understand.

The underlying issue seems to be with closures only being lifetime-generic in special circumstances, but not by default. I think ultimately x in |x| &**x was inferred to have the type &'0 _ (where 0 is some concrete unnameable lifetime) instead of for<'a> &'a _.
In other circumstances (see last example here) explicitly writing : &_ seems to fix it but this wasn't the case here. I had converted everything else to .map(Deref::deref) anyways though, for better readability. This was the only case I seem to have missed, and changing it too fixed the issue.

There really needs to better diagnostics for this kind of thing. It felt like debugging C++ post-monomorphization errors 👀

cc rust-lang/rust#41078, rust-lang/rust#86921 (comment)

@poljar CI fixed :)